System and method for converting requests between different multicast protocols in a communication network

ABSTRACT

The invention provides a system and method for generating and evaluating a request in a protocol from another request formed in another protocol. Therein, the request relates to a change of membership to a group and the group relates a service to a host of the service in a communication network. In particular, the method comprises receiving said request, identifying a target group from said request, identifying an associated host to said target group and generating in another protocol another request containing a reference to said target group and said associated host. The request identifies said group and does not uniquely identify said associated host. The invention provides the ability to block a request from proceeding further if it does not belong to a recognized group.

FIELD OF THE INVENTION

[0001] The invention relates generally to data communications, inparticular to a system and method for interfacing between routers andhosts running internet group management protocols.

BACKGROUND OF THE INVENTION

[0002] Digital media services provide subscribers with access todownloadable video information, such as television programs, movies,audio programs and text-based information streams. Typically,subscribers selectively access such services via a connection to acommunication network. In the network, the services are provided fromone or more information sources. Routers in the network are coupled toboth the sources and the subscribers; the routers provide linkinginterfaces to enable the sources to transmit their services to theintended subscribers in the network.

[0003] Generally, when services are provided to a specific list ofsubscribers in a network, a multicast transmission is used. Therein, onerouter transmits messages to multiple destinations. For multicasttransmissions, a router requires group information identifying membersof a group which are to receive a specified multicast transmission. Inan Internet Protocol (IP) v4 network, Internet Group Management Protocol(IGMP) commands are sent from hosts to routers in the network to manageIP multicast transmissions. IGMP is an evolving protocol. The InternetEngineering Task Force (IETF) has published numerous specifications forIGMP, as its standards evolve, including: RFC 1112, entitled “HostExtensions for IP Multicasting”; RFC 2236, entitled “Internet GroupManagement Protocol, Version 2”; and RFC 3376 entitled “Internet GroupManagement Protocol, Version 3”. All three specifications areincorporated herein by reference. IGMP, version 2 is designed to beinteroperable with Protocol Independent Multicast—Sparse Mode (PIM-SM)multicasting. IGMP, version 3 adds the capability for ProtocolIndependent Multicast—Single Source Multicast (PIM-SSM) multicasting.PIM-SSM provides simplified processing in both the data plane and thecontrol plane over PIM-SM. Unfortunately, some mapping constructs ofIGMP v3 are not compatible with IGMP v2. This is problematic when alegacy host, which recognizes only IGMP version 2 protocol commands, isconnected to a network which utilizes PIM-SSM.

[0004] Therefore, a need exists for a method and apparatus forsupporting multicast group transmissions that provides PIM-SSMcompatibility with legacy protocols.

SUMMARY OF THE INVENTION

[0005] In a first aspect, a method of generating a request in a protocolfrom another request formed in another protocol is provided. The requestis related to a membership change to a group and the group is related aservice provided by a host in a communication network. The methodcomprises receiving the request, identifying a target group from therequest, identifying an associated host to the target group andgenerating in another protocol, another request containing a referenceto the target group and the associated host. For the method, the requestidentifies the group and does not uniquely identify the associated host.

[0006] The service in the method may relate to a multicast transmissionin the network.

[0007] The method may have the host identified by accessing datarelating all hosts to all of their groups which are configured in thenetwork.

[0008] The method may have the data being accessible by each router inthe network.

[0009] For the method, an instance of the data may be stored locally ateach router.

[0010] For the method, each instance of the data may be updated by anetwork manager computer associated with the network.

[0011] For the method, the another protocol may follow IGMP version 2constructs and the request may follow IGMP version 3 constructs.

[0012] The method may have the another request generated at a requestinghost in the network, which is received at a router connected to therequesting host.

[0013] The method may update a forwarding table associated with thegroup to reflect the request.

[0014] In a second aspect, a system for managing and converting arequest in a protocol from another request formed in another protocol isprovided. Therein, the request relates to changing a membership to agroup and the group relates to a service provided by a host in acommunication network. The system comprises a module for receiving theanother request, data relating all hosts to all of their groups whichare configured in the network, an identification module for identifyingan associated host to the target group utilizing the data and ageneration module for selectively generating the request containing areference to the target group and the associated host. In the system,the another request identifies the group and does not uniquely identifythe associated host.

[0015] The system may have the data accessible by each router in thenetwork.

[0016] The system may store an instance of the data locally at eachrouter; each instance of the data may be updated by a network managercomputer associated with the network; the another protocol may followIGMP version 2 constructs; and request may follow IGMP version 3constructs.

[0017] The system further may comprise an evaluation module and ablocking module. The evaluation module evaluates access rights of theanother request to the target group by utilizing membership informationassociated with the host and the target group; the blocking moduleselectively blocks the generation module from generating the request ifthe another request has access rights which are not acceptable.

[0018] In a third aspect, a method of evaluating and converting arequest received in a protocol is provided. Therein, the request relatesto joining a group and the group relates a service provided by a host ina communication network. The method comprises receiving the request,identifying a target group from the request, identifying an associatedhost to the target group, evaluating access rights of the request to thetarget group by utilizing membership information associated with thehost and the target group, blocking the request if the request does nothave acceptable access rights to the target group and generating anotherrequest containing a reference to the target group and the associatedhost if the access rights are acceptable. In the method, the requestidentifies the group and does not uniquely identify the associated host.

[0019] The method may have the request relating to a multicasttransmission in the network; the another protocol may follow IGMPversion 2 constructs; and the request may follow IGMP version 3constructs.

[0020] In other aspects of the invention, various combinations andsubsets of the above aspects are provided.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The foregoing and other aspects of the invention will become moreapparent from the following description of specific embodiments thereofand the accompanying drawings which illustrate, by way of example only,the principles of the invention. In the drawings, where like elementsfeature like reference numerals which may bear unique alphabeticalsuffixes in order to identify specific instantiations of like elements):

[0022]FIG. 1 is a block diagram of a communication network including ahost and a router which operate in accordance with an embodiment of thepresent invention;

[0023]FIG. 2A is a block diagram of a router in the communicationnetwork of FIG. 1 illustrating operational aspects of the embodiment ofFIG. 1; and

[0024]FIG. 2B is another block diagram of the router of FIG. 2Aillustrating additional operational aspects of the embodiment of FIG. 1.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0025] The description which follows, and the embodiments therein, areprovided by way of illustrating an example, or examples, of particularembodiments of principles of the present invention. These examples areprovided for the purpose of explanation, and not limitations, of thoseprinciples. In the description, which follows, like elements are markedthroughout the specification and the drawings with the same respectivereference numerals.

Prior Art Systems

[0026] Referring to FIG. 1, network 100 is shown. Aspects of network 100are shown to illustrate prior art systems and an embodiment of theinvention.

[0027] For a prior art system, network 100 enables network elements tobe connected through cloud 102 to other network elements. In particular,network cloud comprises a series of routers 104 connected bycommunication links 108. As shown, cloud 102 comprises routers 104A,104B, 104C, 104D and 104E. When data traffic is sent from a sourcedevice to a destination device in through network cloud 102, acommunication path through various routers 104 must be defined.

[0028] The architecture of network 102 is preferably IP. Accordingly,address constructs for data traffic and path generation constructsfollow IP constructs. As such, when establishing a path, it is extendedfrom the source device to the destination device in segments bysequentially finding a router which can send the data traffic to anadjacent router which is in a segment of a communication path towardsthe destination device. Each router has a routing table 112 providing amap of the topology of network cloud 102 to assist each router inidentifying a next segment for a routing path for received data traffic.Network manager 110 is connected to cloud 102 and is responsible formaintaining and updating routing tables 112 of each router 104. Networkmanager 110 is connected to each router 104 in cloud 102 via acommunication link 108.

[0029] Hosts 106 are computing devices and each host has an IP address.Each host 106 is connected to a router 104 which provides the point ofconnection for host 106 to network 100. For example, hosts 106A and 106Dare connected to network 100 via router 104A; hosts 106B and 106C areconnected to network 100 via router 104B; host 106E is connected torouter 104E and host 106F is connected to router 104C. Connections aremade via communication links 108. In other embodiments, thecommunication link between the hosts and their connecting router may bea broadband communication link such as an assymetric digital subscriberline, Ethernet connection, local multipoint data service (LMDS), or anasynchronous transfer mode (ATM) passive optical network (APON).

[0030] Some hosts may be used as storage sites for services (for examplehosts 106B and 106D); a host may be a computer (host 106E and 106F) orset-top box (hosts 106A and 106C). A set-top box is used to requestservices from other hosts, such as multicast group transmissions. Whenconfigured to receive multicast transmissions, a set top box issues oneor more requests to the router which connects it to network 100 toreceive a multicast transmission corresponding to programminginformation selected by the user. In such an arrangement, when a userwatching television changes channels, the set top box relays informationconcerning the channel change to the connecting router. Essentially, theset top box indicates to the connecting router that the previouslyviewed channel is no longer required and that a new multicast datastream corresponding to the channel to which the user has selected isrequired. Also, a personal computer may be configured as a host torequest multicast groups in a similar manner as a set top box. Each ofthe hosts may be active or inactive at various points in time, and eachof the hosts may request one or more multicast groups when active.

[0031] Therein, network 100 is used to provide, in part, access todigital video distribution services. A user of television 114 accessnetwork 100 to request downloads of specific video programs offered bythe services from remote hosts 106. The user has a set-top box 106Aconnected to his display device (e.g. his television) and network 100;the set-top box 106A is a host and generates and transmits networkrequests for video programs initiated by the user. When the user wishesto download a video program, he accesses a menu (typically displayed ontelevision 114) and selects the desired video program from the menu. Theset-top box 106A then issues a request to network 100 to receive thevideo program. The request sent by the set-top box 106A is received byrouter 104A, as the point of connection to network 100; in turn, router104A must forward the request towards the source of the video program tonetwork 100. In network 100, the host which provides the video programis host 106B.

[0032] In network 100, hosts 106B and 106D utilize IP multicastingprotocols to have network 100 distribute their programs to requestingset-top boxes or computers. Multicasting provides the benefit ofconserving bandwidth usage in network 100. With multicasting, a host cansend one copy of the multicasted data once to its server rather thanrepeatedly sending the same data to its router, then having its routersend the data to each subscribing service.

[0033] An IP multicast session is defined by sending a packet to areserved multicast IP address, which in IPv4, comprise addresses in theClass D range, encompassing addresses from 224.0.0.0 to 239.255.255.255.Accordingly, by examining the source and destination IP addresses fromthe IP header of a packet, a router can determine over which links 108the packet is to be multicasted. A multicast address identifies aparticular transmission session rather than a specific physicaldestination host. This ensures that a host is able to join an ongoingmulticast session.

[0034] In the prior art, there are three protocols governing theinteraction of hosts and routers operating multicast protocols.

[0035] 1. IGMPv2 interoperating with PIM-SM network, which is astandardized legacy protocol;

[0036] 2. IGMPv3 interoperating with PIM-SM network, which is a recentlystandardized protocol; and

[0037] 3. IGMPv3 interoperating with PIM-SSM network, which is anotherrecently standardized solution.

[0038] The following example illustrates operating aspects of theprotocol #3 where IGMPv3 requests are translated into PIM-SSM requests.To assist implementation a multicast of the video program, each routermaintains a multicast forwarding table (MFT) of hosts associated witheach video program. Each entry in the table has two components: thefirst component provides information on the multicasted program,including its Group's IP address and the source host of the program; thesecond component is a list of outgoing links (108) associated with theprogram. Table A is a representative multicast forwarding table forrouter 104B in network 100. TABLE A MFT Group Multicast Receiving LinksSource S = host 106B (10.1.2.3) Link 108A to Set-top box 106C, Group G =ABC (239.0.0.1) Link 108C to Router 104C Source S = host 106D (10.2.3.4)Link 108E to Router 104E Group G = NBC (239.0.0.9) Source S = host 106B(10.1.2.3) Link 108A to Set-top box 106C Group G = HBO (239.0.0.5)

[0039] The MFT may be included as a part of routing table 112. The MFTneeds to be updated as multicast destinations are added and dropped froma group. In multicast routing, routers communicate with each other toexchange information about multicast group membership information toneighboring routers.

[0040] Using IGMPv3, a host 106A generates a JR (S, G) to router 104A,where S is the IP address of host 106B and G is the group IP address ofABC. Router 104A does a lookup in the unicast routing table on address Sto determine that the reverse path towards the source egresses out link108A towards router 104D. Using PIM-SSM, STB router 104A will generate ajoin request command which has the syntax: JR (S, G). The behaviour ofrouter 104D is similar to 104A and outside the scope of the behaviourbeing described. The resulting Multicast Forwarding Table at Router 104Bis shown in Table B with the change highlighted. TABLE B MFT GroupMulticast Receiving Links Source S = host 106B (10.1.2.3) Link 108A toSet-top box 106C, Group G = ABC (239.0.0.1) Link 108C to Router 104C,Link 108B to Router 104D (and on towards Host 106A) Source S = host 106D(10.2.3.4) Link 108E to Router 104E Group G = NBC (239.0.0.9) Source S =host 106B (10.1.2.3) Link 108A to Set-top box 106C Group G = HBO(239.0.0.5)

[0041] As is discussed in detail below, an embodiment provides anothersystem incorporating IGMPv2 with PIM-SSM network is provided.

Details of an Embodiment

[0042] Generally, the present invention provides a system and method forprocessing multicast group subscriptions for a multicast distributiongroup. When a router has received a request to join a multicast group,but has not been provided the identity of the source of the group, therouter responsively obtains information from a group source table toidentify the source for the group. Next, the router creates a request tojoin the distribution group and sends the request with the sourceinformation to the router associated with the group.

[0043] Again, referring to FIG. 1, the following example illustratesoperating aspects of the embodiment. Unfortunately, legacy set-topboxes, such as set-top box 106A, can only generated IGMP v2 protocolcommands and accordingly, cannot implement an IGMP v3 join requestcommand. The embodiment provides an interface mechanism allowing legacysystems to use IGMPv2 protocols to interface with a network which usesPIM-SSM. Therein, when a legacy set-top box 106A generates an IGMPv2 JR(*, G) request, it is sent to STB router 104A, which then generates acorresponding PIM-SSM JR (S, G) request. Accordingly, when a JR (*, G)request is received by STB router 104A, it needs to identify a source Sfor the group G. After the source is identified, the join request JR (S,G) is sent towards the source host 106 according to standard PIM-SSMprocedures. Generally, PIM-SSM operation is based on a unidirectionaltree whose root is the Source and whose leaves are the receivers. ASource Specific Multicast (SSM) defines a “channel” identified by an (S,G) pair, from source S for SSM destination address G. The tree whichmodels the group is called source-specific tree, or shortest-path tree(SPT).

[0044] An example of construction and use of a SPT for (S1, G1) by theembodiment is provided. Network 100 has receiver/host 106A on subnetwork116A (addressed as 190.1.1/24). Source S1 is associated with subnetwork116B and has address S1=100.1.1/24, G1=232.1.1.1. When multicastreceiver 106A wishes to receive traffic for group G1 from source S1, itmust send a notification to subnetwork 116B. Receiver 106A may send anIGMPv2 or IGMPv3 message to implement this notification to router 104Awhich, in the example, is the designated router in subnetwork 116A.Router 104A tracks groups which are being accessed by receivers 106 inits subnetwork 116A in a tree information base (TIB). When router 104Areceives the IGMP message from receiver 106A, router 104A creates an(S1, G1) entry in its TIB and then places the Ethernet interface E0 inits outgoing interface list which is a list of interfaces that havejoined the group.

[0045] Since router 104A had to create a new (S1, G1) state, router 104Amust send a Join Request (S1, G1) command to the upstream router 104towards source S1. Router 104A consults a multicast topology table todecide where to send the message. In the example, router 104A send aJoin Request (S1,G1) message to router 104D. In this manner, the JoinRequest (S1,G1) message travels hop-by-hop towards S1 for the group G1and, in each router 104 it passes through, a (S1,G1) state isinstantiated. Eventually the Join Request (S1,G1) message either reachesS1, or reaches a router 104 that already has the (S1,G1) Join state.

[0046] Similarly, receivers 104 can request to leave a group. If allreceivers 104 in subnetwork 202 leave a group, router 104, as thedesignated router, sends a Prune (S1,G1) message towards source S1 formulticast group G1.

[0047] In the embodiment, all of the source and group information isstored at each router 104. Management of the source and groupinformation is performed by network manager 110 is a computer in network100. The source and group information is preferably organized in atable. Network manager 110 maintains the contents of the table andensures that information in the table is distributed to all routers 104in network 100. For the embodiment, network manager 110 may use anyknown method to distribute the table over the links 108.

[0048] Table C is an exemplary table of the source and group informationfor a network. Any changes (additions and subtractions) to Table C needto be distributed to all routers 106. For example, if a new channel(e.g. FOX) starts transmitting from a video server, Table C needs to bemodified to include the group and source address of the new channel by anetwork management operator and then the updated table needs to bedistributed to each of the routers. TABLE C Channel (Group G) SourceHost S ABC (239.0.0.1) Host 106B (10.1.2.3) HBO (239.0.0.5) Host 106B(10.1.2.3) NBC (239.0.0.9) Host 106D (10.2.3.4) CBS (239.0.0.12) Host106D (10.2.3.4)

[0049] Using the source and group information, the embodiment generatesa JR (S, G) PIM-SSM command from a JR (*, G) IGMPv2 command as follows,using router 104A as a representative communication device to performthe generation. Router 104A has internal hardware and software modulesto generate the command. In particular aspects of the modules areimplemented in a state machine.

[0050] Initially, router 104A receives the IGMPv2 JR (*, G) message fromhost 106A. Router 104A needs to determine addressing information of thehost of the program. To do this, router 104A accesses a source and groupinformation table. As the STB router knows the identity of group G, thecorrelating source S can be identified from the source and groupinformation table. With the source S information, STB router 104A buildsa PIM-SSM join request placing the source address as determined fromTable B as the “S” IP address in the PIM-SSM JR (S, G). The PIM-SSM issent on a link as determined by a lookup of address S in the unicastrouting table. This will be link 108 towards router 104D.

[0051] In order to facilitate distinguishing amongst groups, it ispreferable that unique multicast addresses are provided to each groupwithin the multicast groups in order to allow IGMP v1/v2 join requests.

[0052] In the embodiment, source and group information is used inconjunction with the “Reverse Path Forwarding” (RPF) lookup as definedin the PIM-SM and PIM-SSM standards. According to the PIM-SM standard,the reception of a (*, G) join results in a special RPF check based on aspecial router in the network named the Rendezvous Point (RP). Asexplained above, this step may not be performed by the embodiment, as itis not needed. In the embodiment, after the source and group informationis examined to determine the source address (S), the source address (S)information is used to perform an RPF lookup to determine the outgoinginterface used to reach address S. In the present example, the outgoinginterface to reach address S (10.1.2.3) is link 108A, which is the linkleading towards router 104D. The embodiment configures the datapath suchthat received (S, G) packets on link 108A are sent out towards host106A. The embodiment then sends a PIM-SSM Join Request (S, G) on link108A towards router 104D.

[0053] Router 104D receives the PIM-SSM Join Request (S, G) and passesthe request to its state machine which performs another RPF lookup onthe source address S1. The state machine determines that the outgoinginterface to reach address S is link 108B leading towards router 104B.The embodiment configures the datapath such that received (S, G) packetson link 108B are sent out towards link 108A.

[0054] Next, the embodiment sends a PIM-SSM Join Request (S, G) on link108B towards router 104B. Router 104B receives the request and passesthe request to its state machine which performs a third RPF lookup onthe source address S. This determines that the outgoing interface toreach address S is link 108C towards host 106B. The embodimentconfigures the datapath such that received (S, G) packets on link 108Care sent out towards link 108B. Now (S, G) traffic from host 106Btraverses network 100 and reaches host 106A.

[0055] For a disconnect request, a similar protocol is followed. Thedisconnect requests must follow the same multicast tree topology as theywere for the join requests.

[0056] Referring to FIG. 2A, further detail is provided on operatingaspects of router 104A. Router 104A has line cards 202A, 202B and 202Cproviding interface points to external devices, such as other routers104 and hosts 106. In particular, line card 202A provides (i) aconnection via communication link 108F to host 106A; and (ii) aconnection via communication link 108A to router 104D. Line card 202Bprovides a connection via link 108D to host 106D. In addition to linksand hosts shown in FIG. 1, in FIG. 2A, line card 202C is shown as havingan additional connection via link 108G to an additional host 106G and anadditional connection via link 108H to an additional host 106H. Router104A also has control module 204 which provides processing of theforwarding information. External devices join the group managed byrouter 104A in the following order: host 106B, router 104D, host 106G,and host 106H. Finally, host 106D transmits IP packets to group addressG1. When host 106D joins the group, host 106D sends an IGMP join messageto join group G1. Then, line card 202B detects join message and providesit line card 202A. It will be appreciated that other routers may beprovided for the embodiment which do not use line cards.

[0057] Referring to FIG. 1, another embodiment provides for selectivelyenabled multicast to secure a network against denial of service attacksinvolving multicast traffic. Another device, besides the video server,would be able to send multicast traffic with a different source addressbut the same group address (S′, G). When the set-top box joins group (*,G) implying the desire to connect to the (S, G) traffic from the videoserver, this feature restricts the traffic received by the set-top boxto the (S, G) traffic. The (S′, G) or any other (*, G) traffic is notsent to the set-top box.

[0058] For example, the ABC channel is carried on group address239.0.0.1 which is carried by source host 106B using source address10.1.2.3 is the authorized carrier of multicast traffic on group address239.0.0.1. Another host 106D in the network is improperly or maliciouslytransmitting on group address 239.0.0.1. The host 106D must do this withits source address 10.2.3.4. The traffic is terminated and not forwardedby Router 104A as there are no subscribers to this improper channel. Noother host can attempt to join this improper channel as on each routerthe group address 239.0.0.1 is mapped to the source address 10.1.2.3.There will be no requests generated for group address 239.0.0.1 with thesource address 10.2.3.4.

[0059] Specifically, referring to FIG. 2B, an embodiment also provides atransmission security feature which blocks unauthorized multicasttransmissions. This security feature utilizes the conversion process ofconverting IGMPv2 join requests (*, G) to IGMPv3 join requests (S, G) toevaluate and exclude unknown malicious sources from transmitting on agiven multi-cast group. The multicast source addresses can be configuredthrough CLI. This feature may be used to prevent denial of service (DOS)attacks on a network source which supports multicast traffic.

[0060] As noted above, router 104 has line cards 202 which provideconnection points between it and each connected host 106 and router 104.Within each line card 202, an interface 204 is provided, which may beselectively activated or deactivated by its router 104, depending onconfiguration constructs. In alternative embodiments, an interface 204may be remotely controlled. When an interface 204 is deactivated, nodata traffic received through its interface 204 will be forwarded by therouter 104 to any other point in the network. Such data traffic maysimply be discarded by the router 104.

[0061] Referring to FIGS. 1 and 2B, following are instances of packetsbeing discarded when received from a multicast source (either from ahost 106 or another router 104):

[0062] If a multicast group associated with router 104A, for example,group G1, is empty, there is no interface associated with it. When host106D transmits IP packets to router 104A via its interface 204, as GroupG1 is empty, the interface is disabled and packets sent by host 106D torouter 104A which is received through interface 204A, interface 204B isdisabled as a multicast source. As such, multicast packets received fromhost 106D are discarded by router 104A.

[0063] If interface 204A is disabled and if host 106F initiates a IGMPJoin Request (host 106A, G1), router 106C sends a PIM-SSM Join request(104A, G1) towards router 104A, no multicast forwarding tree is createdsince interface 204A is disabled as a multicast source. As such,multicast packets received from host 106C are discarded by router 104A.

[0064] If Group G2 is configured on router 104A, but has no receiverassociated with it, then if host 106E transmits IP packets to multicastgroup address G2, router 104E forwards the packets to router 104Athrough interface 204A. However, here, there is no member in group G2 onrouter 104A; as such, router 104A discards packets since there is noreceivers.

[0065] Host 106D sends an IGMP Join Request (G2) using IGMPv2. However,the group (host 106D, G2) is not configured on router 104A. As amulticast forwarding tree is not created since source of G2 is unknown,packets are discarded by router 104A.

[0066] It will be appreciated that other configurations for router 104Amay also be provided to prevent DOS attacks.

[0067] The foregoing embodiment has been described with a certain degreeof particularity for the purposes of description. Those skilled in theart will understand that numerous variations and modifications may bemade to the embodiments disclosed herein without departing from thescope of the invention.

What is claimed is:
 1. A method of generating a request in a protocolfrom another request formed in another protocol, said request relatingto a change of membership to a group, said group relating a service to ahost of said service in a communication network, said method comprising:receiving said request; identifying a target group from said request;identifying an associated host to said target group; and generating inanother protocol another request containing a reference to said targetgroup and said associated host, wherein said request identifies saidgroup and does not uniquely identify said associated host.
 2. The methodof generating a request in a protocol from another request formed inanother protocol as claimed in claim 1, wherein said service is amulticast transmission within in said network.
 3. The method ofgenerating a request in a protocol from another request formed inanother protocol as claimed in claim 2, wherein said host is identifiedby accessing data relating all hosts to all of their groups which areconfigured in said network.
 4. The method of generating a request in aprotocol from another request formed in another protocol as claimed inclaim 3, wherein said data is accessible by each router in said network.5. The method of generating a request in a protocol from another requestformed in another protocol as claimed in claim 4, wherein an instance ofsaid data is stored locally at said each router.
 6. The method ofgenerating a request in a protocol from another request formed inanother protocol as claimed in claim 5, wherein each said instance ofsaid data is updated by a network manager computer associated with saidnetwork.
 7. The method of generating a request in a protocol fromanother request formed in another protocol as claimed in claim 6 whereinsaid another protocol follows IGMP version 2 constructs and said requestfollows IGMP version 3 constructs.
 8. The method of generating a requestin a protocol from another request formed in another protocol as claimedin claim 7 wherein said another request is generated at a requestinghost in said network and is received at a router connected to saidrequesting host.
 9. The method of generating a request in a protocolfrom another request formed in another protocol as claimed in claim 8wherein an update reflecting said request is performed to a forwardingtable associated with said group.
 10. A system for managing andconverting a request in a protocol from another request formed inanother protocol, said request relating to a membership change to agroup, said group relating a service to a host in a communicationnetwork, said system comprising: a module for receiving said anotherrequest; data relating all hosts to all of their groups which areconfigured in said network; an identification module for identifying anassociated host to said target group utilizing said data; and ageneration module for selectively generating said request containing areference to said target group and said associated host, wherein saidanother request identifies said group and does not uniquely identifysaid associated host.
 11. The system for managing and converting arequest in a protocol from another request formed in another protocol,as claimed in claim 10, wherein said data is accessible by each routerin said network.
 12. The system for managing and converting a request ina protocol from another request formed in another protocol, as claimedin claim 11, wherein an instance of said data is stored locally at saideach router; each said instance of said data is updated by a networkmanager computer associated with said network; said another protocolfollows IGMP version 2 constructs; and said request follows IGMP version3 constructs.
 13. The system for managing and converting a request in aprotocol from another request formed in another protocol, as claimed inclaim 12, wherein said system further comprises an evaluating module toevaluate access rights of said another request to said target group byutilizing membership information associated with said host and saidtarget group; and a blocking module to selectively block said generationmodule from generating said request if said another request does notsaid access rights are not acceptable.
 14. A method of evaluating andconverting a request received in a protocol, said request relating tojoining a group, said group being relating a service provided by a hostin a communication network, said method comprising: receiving saidrequest; identifying a target group from said request; identifying anassociated host to said target group; evaluating access rights of saidrequest to said target group by utilizing membership informationassociated with said host and said target group; and blocking said hostfrom said target group if said request does not have acceptable accessrights to said target group; and generating another request containing areference to said target group and said associated host if said accessrights are acceptable, wherein said request identifies said group anddoes not uniquely identify said associated host.
 15. The method ofevaluating and converting a request received in a protocol, said requestbeing to distribute a file to a group 14, wherein said service is amulticast transmission to said network; said another protocol followsIGMP version 2 constructs; and said request follows IGMP version 3constructs.